In current multi-processor systems, semaphores are used to provide a mechanism for preventing concurrent accesses to shared resources (e.g., memory regions). When used properly, semaphores help to ensure that the processors access any particular shared resource serially, rather than concurrently, so that the shared resource may remain coherent.
In some systems, semaphores are implemented in software. More specifically, before a processor accesses (e.g., updates or writes to) a shared resource, the processor is required, by software convention, to determine whether a semaphore associated with the shared resource currently is locked by another processor. If not, the processor may lock the semaphore and access the shared resource, and other processors should avoid concurrent accesses to the shared resource. Only the processor that locked the semaphore may access the shared resource, and only that processor may unlock the semaphore after the access has been completed. Once the semaphore has been unlocked, another processor may attempt to lock the semaphore in order to reserve access to the shared resource.
In other systems, semaphores are implemented in hardware. For example, a system may include dedicated semaphore hardware (e.g., registers, logic circuitry, and so on) associated with various shared resources. When a processor locks a particular hardware semaphore, the hardware semaphore ensures that no other processor may perform a concurrent access to the resource protected by the semaphore. In other words, the semaphore is enforced by the hardware, rather than being enforced by each processor adhering to a particular software convention.
Software and hardware implemented semaphores each have various advantages and disadvantages. For example, although software semaphores may be implemented without extensively modifying the system architecture, implementation of software semaphores places a large computational burden on the processors. In addition, a risk is present that a processor may not properly follow the required semaphore usage protocol, which may lead to non-coherent accesses of shared resources. Proper system operation is guaranteed only when the processors use the semaphores in the correct manner. Failure to follow the required protocols, either because of a programming error or malicious software, may manifest itself in any of a number of error conditions (e.g., data corruption, system hangs, system crashes, and so on). Conversely, hardware semaphores do not typically consume extensive processor resources, and the risk of non-coherent accesses due to processor non-compliance is lower than for software-implemented semaphores. However, because each semaphore is implemented using specific hardware, the number of hardware semaphores implemented in a system is limited based on the amount of system real estate that may be dedicated to semaphores, routing between the processors and the semaphore hardware, and other considerations. Accordingly, methods and apparatus for implementing semaphores are desired, which overcome at least some of the disadvantages of prior systems.